The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In a business-to-business environment, applications executing on computers commonly communicate with other applications that execute on other computers. For example, an application “A” executing on a computer “X” might send, to an application “B” executing on a computer “Y,” a message that indicates the substance of a purchase order.
Computer “X” might be remote from computer “Y.” In order for computer “X” to send the message to computer “Y,” computer “X” might send the message through a computer network such as a local area network (LAN), a wide-area network (WAN), or an inter-network such as the Internet. In order to transmit the message through such a network, computer “X” might use a suite of communication protocols. For example, computer “X” might use a network layer protocol such as Internet Protocol (IP) in conjunction with a transport layer protocol such as Transport Control Protocol (TCP) to transmit the message.
Assuming that the message is transmitted using TCP, the message is encapsulated into one or more data packets; separate portions of the same message may be sent in separate packets. Continuing the above example, computer “X” sends the data packets through the network toward computer “Y.” One or more network elements intermediate to computer “X” and computer “Y” may receive the packets, determine a next “hop” for the packets, and send the packets towards computer “Y.”
For example, a router “U” might receive the packets from computer “X” and determine, based on the packets being destined for computer “Y,” that the packets should be forwarded to another router “V” (the next “hop” on the route). Router “V” might receive the packets from router “U” and send the packets on to computer “Y.” At computer “Y” the contents of the packets may be extracted and reassembled to form the original message, which may be provided to application “B.” Applications “A” and “B” may remain oblivious to the fact that the packets were routed through routers “U” and “V.” Indeed, separate packets may take separate routes through the network.
The route that a packet takes through a network might not be secure. Parties intermediate to applications “A” and “B” in the network might be able to intercept packets and determine the packets' contents. Under circumstances where packets contain confidential or sensitive information, the consequences of such illicit interception can be disastrous.
In order to prevent intermediate parties from understanding intercepted packets and using the contents thereof for illicit purposes, applications may encrypt messages prior to sending packets that contain those messages through an untrusted network. One popular method of encryption is public key encryption. For example, application “A” might want to send a message to application “B” using public key encryption. Therefore, application “A” might encrypt the message using application “B's” public key. In encrypted form, the message is not understandable. Because the message is encrypted using application “B's” public key, only application “B's” private key can be used to decrypt the message, and only application “B” possesses application “B's” private key. Application “A” might send the encrypted message within one or more packets to application “B” as described above. Upon receiving the encrypted message, application “B” may use application “B's” private key to decrypt the message. Thus decrypted, the message is in the same form as before the message was encrypted. Another method of encryption is symmetric key encryption, in which both applications “A” and “B” use the same key to encrypt and decrypt messages, and only applications “A” and “B” possess the key.
In practice, the above encryption/decryption process can be more complicated than it initially seems. Taking public key encryption as an example, application “A” needs to obtain application “B's” public key before application “A” can encrypt messages to be sent to application “B.” To provide application “B's” public key to application “A,” a user of application “B” might e-mail the public key to a user of application “A.” If this approach is used widely, then the user of application “B” will need to e-mail the public key not only to the user of application “A,” but also to every potential sender of encrypted messages to application “B.” There might be multitudes of such senders.
Complicating this situation is the fact that private keys sometimes expire or become lost. For example, if the hard drive of computer “Y” crashes, and if application “B's” private key was only stored on the hard drive (not an unreasonable scenario, given the private nature of the key), then application “B's” private key will be lost and application “B” will need to generate a new private key. Regardless of the reasons for needing to generate a new private key, along with the new private key, application “B” will need to generate a new corresponding public key; the new private key cannot be used to decrypt messages that have been encrypted using the old public key, so application “B” will need to inform all of the senders mentioned above that the old public key is no longer valid and that the new public key should be used instead.
The plight of application “A” is also considerable. Application “A” might send encrypted messages to many different recipients. Each recipient might have a different public key. It may be difficult for the user of application “A” to keep so many different public keys organized and up-to-date. If the e-mail approach to key distribution is used, then much of a user's time might be consumed with sending and receiving public keys or symmetric keys.
It is possible that only some, and not all, messages sent by application “A” ought to be encrypted. For example, application “A” might reside on the same trusted network as another application “C,” and therefore, application “A” would not need to encrypt messages that are to be sent to application “C.” For another example, application “A” might send, to another application “D,” messages that are not confidential or sensitive in nature, and therefore, application “A” would not need to encrypt messages that are to be sent to application “D.”
Because encryption and decryption sometimes involves significant processing overhead, not to mention the key exchanges discussed above, avoiding unnecessary encryption and decryption is often desirable. However, as matters stand, the determination of whether to encrypt or decrypt a message is often made on a message-by-message basis by an application's user, even in cases where the user knows with reasonable certainty beforehand that all messages having certain common characteristics do or do not need to be secured. These all-too-frequent determinations burden users and consume time that might otherwise be applied to more meaningful pursuits.
Thus, the “application-managed security” approach described above is impractical when applied to systems in which large numbers of applications need to communicate with each other in a secure manner. A more practical technique for allowing a multitude of applications to communicate with each other in a secure manner is needed.